The ACL settings in Process Platform allow users to define all the ACL objects in a single tree for a particular user or role. For example, if the ACL is set under metadata services, a single object maintains the ACL settings for tables, fields, related tables, and stored procedures. There is one such object for each metadata service for a particular user or role. Similarly, when ACL is set at the Service Group level, there is one ACL object per Service Group. At the namespace level , there is a single object for the whole organization, which has ACL for Web service Interfaces and Web service operations. The following sections describe the ACL definitions for various services available in Process Platform.

OLE DB Services

The object hierarchy for OLE DB Services is Database > Table > Field .

Here, the ACL for a lower level can be specified as open although the higher level may be blocked. In other words, a field can be open to a user even if the table and the database are blocked.

Given below is a sample unconditional ACL object tree which blocks the FirstName field of the Employees table and the EmployeeID field of the Orders table for update and insertion respectively, in the Northwind database.

<object condition="false">
    <object id="Northwind">
        <object id="Employees">
            <object id="FirstName">
                <method acl="blocked" id="update"/>
            </object>
        </object>
        <object id="Orders">
            <object id="EmployeeID">
                <method acl="blocked" id="insert"/>
            </object>
        </object>
    </object>
</object>

Given below is a sample conditional ACL object tree which allows users to update only those records of the Employees table of the Northwind database, where the value in the EmployeeID field is greater than 4.

<object condition="true">
    <object id="Northwind">
        <object id="Employees">
            <method acl="condition" id="update">EmployeeID in [3,5] and FirstName = 'Nancy'</method>
        </object>
    </object>
</object>

Database Stored Procedures

The ACL settings for OLE DB RPC Services is Database > Stored Procedure Method Name.
Given below is a sample ACL object tree, which is a modified version of the object tree given above. This blocks the stored procedure CustOrdersOrders in the Northwind database.

<object>
    <object id="Northwind">
        <object id="Employees">
            <object id="FirstName">
                <method acl="blocked" id="update"/>
            </object>
        </object>
        <object id="Orders">
            <object id="EmployeeID">
                <method acl="blocked" id="insert"/>
            </object>
        </object>
        <object acl="blocked" id="CustOrdersOrders"/>
    </object>
</object>

Note: ACL definition for JDBC services is same as OLEDB services except in case of stored procedures. ACLs are not defined for JDBC stored procedures.

Java Call and Java Services

ACL Settings for Java call and Java services can be applied only at the Service Group and Application levels.

COMCall Services

ACL Settings for COMCall Services can be applied only at the Service Group and Applications levels.

XML Store Objects

ACL can be set on files or folders that are located in the XML Store. When ACL is set on a folder in the XML store, the ACL settings are applicable to all files under that folder, unless otherwise specified.

The hierarchy of ACL settings for XML store objects is defined by the structure of the XML Store Explorer and the location of the required object in the XML tree.

ACL at the XML Store level can be set at the object or Web service operation level:

• If a file is blocked at the object level, it is blocked for reading.
• A file can be blocked at the Web service operation level forRead, Update, Insert or Delete.
• If a folder is blocked at the object level, it is blocked for reading. In this case, the user sees it as an empty folder. However, the objects within the folder can still be open.
• If a folder is blocked at the Web service operation level, the objects within the folder can be open.
  
  Given below is a sample ACL object tree, which blocks the Application Package folder of the XML Store. However, the user can read the copyfile object under the Application Package folder.

  <object>
      <object id="isv">
          <object id="cordys">
              <object id="wcp">
                  <object id="menu">
                      <object id="isv package" acl="blocked">
                          <object id="copyfile" acl="open">
                              <method id="update" acl="blocked" />
                          </object>
                      </object>
                  </object>
              </object>
          </object>
      </object>
  </object>
  <object>
      <object id="user">
          <object id="cordys">
              <object id="wcp">
                  <object id="menu">
                      <object id="isv package">
                          <object id="copyfile">
                              <method id="read" acl="blocked" />
                          </object>
                      </object>
                  </object>
              </object>
          </object>
      </object>
  </object> 

  
  In the above example, the top level object inside which the whole ACL tree is set includes an attribute ID that denotes the version of the XML object blocked. As shown, ACL can be set for application, organization, or user versions of the same XML Object.

LDAP Objects

ACL can also be implemented for LDAP objects. This can be done in the following ways:

• Object level access control - This creates an
  acobjecttree from the DN of an LDAP entry
• Object-type level access control - This creates an acobjecttree based on the object class of an LDAP entry
  
  For each type of control, the Web service operation can be set appropriately. Currently, this has been implemented for the following LDAP Web service operations:
• GetLDAPObject
• Update
  
  The following is an example of an acobjecttree in LDAP:

  <object>
      <object id="dn">
          <object id="o=acme.com">
              <object id="cn=cordys">
                  <object id="o=system">
                      <object acl="open" id="cn=organizational users">
                          <object id="cn=jsmith">
                              <method acl="blocked" id="read"/>
                          </object>
                      </object>
                  </object>
              </object>
          </object>
      </object>
      <object id="objectclass">
          <object id="top">
              <method id="read">read</method>
          </object>
          <object id="busorganizationalobject">
              <method id="read"/>
          </object>
          <object id="busorganizationaluser">
              <method id="read"/>
          </object>
      </object>
  </object>
  

  
  Note:

1. For LDAP ACL settings, the Object ID (CN of the actual LDAP Object) must be specified in RFC format, that is all letters in lowercase (For example: cn=Process Platform northwind demo 1.0).
2. When setting the ACL through metadata services, the top level object tag need not have an ID attribute, implying that these settings are independent of the Service Groups.
3. For ACL settings to function properly, ensure that you set the method tag for any ACL setting immediately below the object tag.